[pull] master from supabase:master - #1136

…48685)

## Problem

Clicking a bar in a usage chart (e.g. the Postgres activity chart on the
project dashboard) navigates to Unified Logs with the log_type filter
applied correctly, but the clicked bar's time range is silently dropped:
the page falls back to the default last-hour window. If the actual
matching logs are outside that window, the main list shows "No results
found" even though the sidebar facet count (computed from the correct
deep-linked range) shows a nonzero count.

Root cause: the table's initial `columnFilters` state was seeded only
from the `filter` URL param, never from `date`. A debounced effect syncs
`columnFilters` back into the URL shortly after mount, and for the
`date` field it treats a missing `columnFilters` entry as a cleared
brush, overwriting the deep-linked `date` param with null.

## Fix

Added `buildDefaultColumnFilters` in `UnifiedLogs.filters.ts`, which
seeds a `date` entry into the initial `columnFilters` from `search.date`
when present, alongside the existing filter-param seeding.
`UnifiedLogs.tsx` now uses this helper instead of building
`defaultColumnFilters` inline, so a deep-linked range survives the
debounced round-trip instead of getting nulled out.

## How to test

- On the project dashboard, click a bar in a usage chart (e.g. Postgres
activity) for a time period further back than the last hour.
- Expected result: Unified Logs opens with both the log_type filter and
the clicked bar's date range applied, and the row list matches the
sidebar facet count instead of showing "No results found".
- `UnifiedLogs.filters.test.ts` has unit tests covering the new seeding
behavior.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
  * Improved log filtering from URL parameters.
  * Preserved valid date ranges when opening deep-linked log views.
* Prevented malformed or duplicate date filters from appearing in the
logs table.

* **Tests**
* Added coverage for valid, missing, malformed, and duplicate date
filter scenarios.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

)

## Problem

When the table editor showed a "Failed to load tables" or "Failed to
load schemas" error (for example, when the underlying database or API
gateway is unhealthy), there was no working way to restart the project
from that error state. Restarting only worked by navigating to Project
Settings.

## Fix

"Failed to load tables" goes through the existing `ErrorMatcher`
classification system, which only showed troubleshooting steps
(including a restart action) for connection-timeout errors. Added an
`ERROR_MAPPINGS` entry for the unclassified/generic API error case,
reusing the existing `RestartDatabaseTroubleshootingSection` and
`RestartProjectDialog` components already used for connection timeouts.

"Failed to load schemas" (in the shared `SchemaSelector`, used across
the table editor and several Database pages) only offered a retry. Added
a "Restart database" button next to it, wired to the same
`RestartProjectDialog`.

## How to test

- In the table editor, trigger a table-load failure that isn't a
connection timeout (any generic API error). The error card should now
show a "Try restarting your project" step with a working restart action.
- Open the schema selector while schemas fail to load (e.g. mock a 503
from the schemas query). A "Restart database" button should appear next
to "Reload schemas" and open the restart confirmation dialog.
-
`apps/studio/components/interfaces/ErrorHandling/ErrorMatcher.test.tsx`
and `apps/studio/components/ui/SchemaSelector.test.tsx` cover both
cases.

FE-4054

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
  * Added database restart guidance when schema loading fails.
* Added options to reload schemas or restart the database, including a
confirmation prompt.
* Added troubleshooting guidance for unclassified table-loading errors.

* **Bug Fixes**
* Improved error handling by displaying relevant fallback guidance for
unknown errors while preserving classified troubleshooting instructions.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

## Summary

Updates SDK reference docs and the client-side tracing guide based on
recent releases across all six Supabase SDKs.

## SDKs analyzed

| SDK | Repo | Latest commit | Latest tag |
|-----|------|--------------|------------|
| js | supabase/supabase-js | `e4e8864` | v3.0.0-next.29 |
| dart | supabase/supabase-flutter | `c3e3602` |
yet_another_json_isolate-v2.1.1 |
| py | supabase/supabase-py | `6570638` | v3.0.0a1 |
| swift | supabase/supabase-swift | `ebef170` | v2.51.0 |
| kt | supabase-community/supabase-kt | `e23df20` | 3.7.0-beta-1 |
| csharp | supabase-community/supabase-csharp | `3fad62f` | v1.1.2 |

## Documentation changes

### `apps/docs/spec/supabase_dart_v2.yml`

- **OAuth Server API**
([supabase-flutter#1561](supabase/supabase-flutter#1561)):
Added `oauth-server-api` group stub and `listGrants()` / `revokeGrant()`
method entries, matching the existing `common-client-libs-sections.json`
nav IDs.
- **`listBuckets()` options**
([supabase-flutter#1557](supabase/supabase-flutter#1557)):
Added example showing `ListBucketsOptions` with `search`, `limit`,
`offset`, `sortColumn`, and `sortOrder`.

### `apps/docs/spec/supabase_py_v2.yml`

- **`on_postgres_changes` `select` param**
([supabase-py#1524](supabase/supabase-py#1524)):
Added `listening-to-selected-columns` example for the new `select=["id",
"name"]` parameter.
- **Expanded filter operators**
([supabase-py#1524](supabase/supabase-py#1524)):
Updated `listening-to-row-level-changes` note to list all supported
operators (`eq`, `neq`, `lt`, `lte`, `gt`, `gte`, `in`, `like`, `ilike`,
`is`, `match`, `imatch`, `isdistinct`) plus `not.` prefix and comma-AND.

### `apps/docs/spec/supabase_swift_v2.yml`

- **OpenTelemetry tracing setup**
([supabase-swift#1101](supabase/supabase-swift#1101)):
Added `initialize-client-with-opentelemetry` example under the
`initializing` section documenting the `OpenTelemetry` SwiftPM package
trait, provider wiring, and known `_invokeWithStreamedResponse`
limitation.

### `apps/docs/content/guides/telemetry/client-side-tracing.mdx`

- **Merged Swift and Dart tracing docs** into the existing JS guide
([supabase-swift#1101](supabase/supabase-swift#1101),
[supabase-flutter#1564](supabase/supabase-flutter#1564)).
- **Converted to tabbed layout** (`<Tabs queryGroup="language">`) with
JavaScript / Swift / Dart tabs, matching the pattern used across other
multi-SDK guides.
- Updated title to "Client-side tracing" and nav label accordingly.

## SDKs with no doc-worthy changes

- **js**: Bug fixes only (auth session clearing, realtime heartbeat
suppression) — no new API surface.
- **kt**: PKCE for `resend()` — behavioral enhancement, no new spec
entry needed.
- **csharp**: Chore/compliance/maintenance only.

---

🤖 Generated with [Claude Code](https://claude.com/claude-code)

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **Documentation**
* Added Dart “OAuth Server” API docs for listing OAuth grants and
revoking grants (including signed-in context and the `clientId`
parameter), with examples.
* Extended Dart Storage docs with a new `listBuckets` example using
`ListBucketsOptions` for filtering, pagination, and sorting.
* Updated Python Realtime docs with generalized PostgREST-style row
filter operators and added examples for listening to selected columns.
* Reworked the “Client-side tracing” guide across JS, Swift, and Dart,
including expanded configuration and troubleshooting (trace propagation
and `traceparent` details).
  * Renamed the telemetry navigation label to “Client-side tracing.”
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>

## What

PR 7 of the SQL-editor query-source (Database vs Logs) stack. Surfaces
`log_sql` snippets as a distinct query source across the SQL editor
sidebar. Stacked on **`charislam/toolbar-ui-creation-flow`** (PR 6 —
toolbar UI + creation flow); review/merge that first.

Nothing is user-visible until the flags roll out — every entry point
requires **both** `sqlEditorLogsSource` **and** `otelLegacyLogs`.

## Changes

- **Nav** — a flag-gated **Logs** section (`LogsSnippetsSection`) backed
by its own single-type `log_sql` query. The active snippet is injected
only into the section it belongs to, via a shared
`withActiveSnippet(snippets, active, belongsPredicate)` helper (also
DRYs the private/favorites/shared injections).
- **Search** (`SearchList`) — a **Logs** result group with a shared,
extracted `SqlSnippetTree`; the "N results found" count now sums
database + logs, with loading/empty states covering both queries.
- **Tabs** — an immutable `sqlSource` field on tab/recent-item metadata
(set at tab creation, lazily backfilled once the snippet loads via
`useEffectEvent`), and a distinct `ScrollText` icon via a shared
`LogsSnippetIcon`. Tab cleanup treats `log_sql` tabs as live and only
prunes them when logs data is authoritative (`canPruneLogsTabs`), so a
disabled/erroring logs query never wrongly deletes logs tabs or blocks
database-tab cleanup.
- **Data layer** — `useSqlSnippetsQuery` gains an optional `type` param
so logs reuse the same `SnippetWithContent` shape as the other sections
(no casts).

## Tests

- `state/tabs.test.ts` — `sqlSource` backfill + creation-time
carry-through.
- `components/layouts/Tabs/Tabs.utils.test.tsx` — cleanup prunes stale
database/logs snippets, keeps live ones, and preserves logs tabs when
logs data isn't authoritative.

## Verification

- `pnpm --filter studio typecheck` ✓
- `pnpm --filter studio run lint:ratchet` ✓
- `pnpm test:studio` (affected suites) ✓

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

* **New Features**
* Added a collapsible Logs section to the SQL editor sidebar for
browsing, sorting, selecting, renaming, and deleting log queries.
* Expanded SQL search with separate, paginated results for database and
log queries.
* Added dedicated log-query icons across navigation, tabs, previews, and
recent items.
* **Bug Fixes**
* Improved tab and recent-item cleanup while preserving active log
queries and accurate source metadata.
* **Tests**
* Added coverage for log tab cleanup and SQL source metadata
synchronization.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

…ckHouse (#48501)

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Feature, plus a refactor of the shared logs-rewrite flow.

PR 8 of the SQL editor query-source series. Stacked on #48457 — review
that one first, and merge this after it.

## What is the current behavior?

A `log_sql` snippet runs against the ClickHouse-backed analytics
endpoint, but the SQL editor's AI still writes Postgres: inline edits
get Postgres system prompts, and the result is run through
`sql-formatter`, which mangles ClickHouse backticks and `log_attributes`
map lookups.

Legacy Logs Explorer saved queries open in the editor as `log_sql`
snippets. Those are BigQuery dialect and error against the ClickHouse
endpoint the editor runs them on, with no in-editor way out — only the
Logs Explorer offered a rewrite.

The completion route was also asymmetric. It assembled a
schema/code/instruction message for Postgres but forwarded `prompt`
verbatim for ClickHouse, so a client wanting ClickHouse had to
hand-build the equivalent string.

## What is the new behavior?

**Inline AI speaks ClickHouse for logs snippets.** `sqlSourceToDialect`
maps a snippet's source to `postgres`/`clickhouse` and
`buildCompletionRequestBody` threads it through. For ClickHouse,
`useSqlEditorAi` strips code fences from the response and skips
`formatSql`. Execution and dialect both follow the snippet type, so a
snippet's valid dialect never flips.

**Rewrite to ClickHouse in the editor.** A banner offers the rewrite for
a logs snippet whose text trips `looksLikeLegacyLogsQuery`, and proposes
the result through the editor's existing AI diff view rather than
replacing the snippet, so it's accepted or discarded like any other AI
edit. Gated on `otelLegacyLogs`: on a non-migrated org the BigQuery text
is still correct, so rewriting it would break a working query.

The offer is a state machine (`offered` / `rewriting` / `failed` /
`noRewriteNeeded` / `dismissed`) with a declarative table of valid
transitions, so the states are mutually exclusive by construction and
dismissal is terminal. A failure keeps its message and offers a retry; a
response identical to the input is reported rather than opening an empty
diff.

**One place assembles completion prompts.** The route now uses a single
template for both dialects, branching only the schema section and — for
`intent: 'rewrite'` — the instruction. `lib/ai/clickhouse-logs.ts` is
the single home for ClickHouse-logs prompt content, replacing two
independently maintained descriptions of the same table. Clients carry
no prompt text.

**The rewrite flow is shared with the Logs Explorer.** Both surfaces
previously hand-rolled the same sequence and had drifted: only one
detected a no-op rewrite, they sourced `log_attributes` keys
differently, and the Explorer formatted errors with an `as Error` cast.
Both now use `useLegacyLogsRewrite` and the same state-driven banner, so
the Explorer picks up no-op detection and typed error extraction.

**Attribute keys are fetched on submit, not while typing.** The detected
source would otherwise feed a reactive query key, making every edit that
changed it cost another network call. `useLogsAttributeKeys` is
imperative and goes through `queryClient.fetchQuery`, so a source
already cached — including by the Explorer header and query panel, which
subscribe reactively — is reused. This also closes a gap where inline
edits never received keys at all, unlike full rewrites.

`getErrorMessage` gains an optional typed fallback and no longer
stringifies a bare object into `'[object Object]'`; every existing
caller already hand-rolled a fallback, except `QueueSettings`, which
interpolated the raw result and now passes one.

Nothing here is user-visible until the `sqlEditorLogsSource` flag is
enabled.

Tests: dialect selection and request-body shape, the ClickHouse prompt
content (including that the schema section does not restate the dialect
rules), the reducer's valid and invalid transitions,
`shouldOfferLegacyLogsRewrite`, on-submit key discovery with cache
reuse, and `getErrorMessage`.

## Additional context

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **New Features**
* Added an Assistant banner to help rewrite legacy BigQuery-style logs
queries into ClickHouse SQL.
* SQL assistance now adapts to the selected query type, including
relevant log attribute context.
* Rewrite suggestions can be reviewed as editor diffs before being
applied.

* **Bug Fixes**
* Improved rewrite failure handling, retry options, dismissal behavior,
and “no rewrite needed” messaging.
* Error notifications now provide a clearer fallback message when
details are unavailable.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Feature — final PR (9/9) of the SQL editor logs-source stack.

**Base branch:** `charislam/sql-editor-inline-ai-clickhouse-dialect` (PR
8). Nothing here is user-visible: entry points stay behind
`sqlEditorLogsSource` + `otelLegacyLogs`, and flag rollout happens after
the whole stack merges.

## What is the current behavior?

- The Assistant has no idea a SQL editor snippet targets the logs
backend. Ask it about a logs snippet and it answers in Postgres, because
the attached query is fenced as ` ```sql ` and nothing tells the model
otherwise.
- Because the `sql` fence is what `MessageMarkdown` treats as runnable
Postgres, an attached ClickHouse query is rendered with a
Run-against-Postgres affordance and branded with `untrustedSql`.
- "Debug with Assistant" on a failed logs query produces a dialect-less
prompt, so both the in-app assistant and the copyable version get
debugged as Postgres.
- A report referencing a `log_sql` snippet runs its ClickHouse SQL
against the user's Postgres database and surfaces the resulting error.

## What is the new behavior?

**Assistant panel.** The "Current Query" chip records which backend the
attached query targets. That reaches the model two ways: each attachment
is fenced with its own dialect (` ```clickhouse ` vs ` ```sql `), and a
`containsLogsSnippets` flag rides on the user message as AI SDK
`metadata`. The server reads the flag off the conversation and prepends
the ClickHouse dialect rules plus the logs schema reference as a
non-cached context message.

Two design points worth calling out in review:

- The flag lives on the **message**, not the request body, so Retry and
the tool-approval continuation reproduce the context a message was
originally asked in — neither of those passes a per-call body.
- It's derived from **what's actually attached**, so detaching the chip
drops the claim rather than leaving the two able to disagree.

The `clickhouse` fence also keeps a logs query out of
`MessageMarkdown`'s `sql` branch, so it's no longer offered as runnable
Postgres or branded with `untrustedSql` — a boundary this stack's
distinct brands exist to prevent crossing.

**Debug flow.** `buildDebugChatArgs` attaches its query with a source
for the same reason, and names the dialect in the prompt text so the
copyable version stands on its own outside the app.

**Reports.** A report only stores a snippet id, so whether it queries
the logs backend is only knowable once the content loads. `ReportBlock`
guards on the fetched type and renders a `LogsSnippetReportBlock`
placeholder instead of executing. Double-guarded: no `sql` for a logs
snippet (so it's out of the query key and `queryFn` short-circuits even
on an explicit `refetch`) and `enabled` excludes it.

**Incidental cleanups.** `buildAssistantContextMessages` extracted out
of `generate-assistant-response`; a schema-access sentinel that was
duplicated as a string literal across two files (and compared against)
replaced with one exported constant; `SqlSnippet` deduplicated to a
single declaration; `resolveSnippetSource` / `isLogsSource` shared
instead of re-implemented per surface.

**Tests.** 4 new/extended suites. Notable cases pinned: a message with
no metadata must validate (`safeValidateUIMessages` applies
`metadataSchema` to *every* message, so a required schema would 400
every existing conversation); only *user* messages count, so a model
reply can't talk the server into a different dialect; a mixed-attachment
message is flagged without overclaiming a single source; and
`ReportBlock` registers no pg-meta mock for the logs cases, so an
unhandled request failing the test *is* the assertion that logs SQL
never reaches Postgres.

Verified: `pnpm typecheck`, `lint:ratchet` (no regression), Prettier,
and the full Studio suite (459 files / 4969 tests).

## Additional context

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

- **New Features**
- Added support for recognizing log snippets in reports, with clear
guidance to open them in the SQL editor or remove them.
- AI Assistant now understands log snippets and provides
ClickHouse-specific context, formatting, and troubleshooting guidance.
- Snippets retain their source information when shared with the AI
Assistant.

- **Bug Fixes**
- Prevented unsupported log snippets from being executed as regular
database queries.
  - Improved source detection when opening snippets directly from links.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

It's a me.

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

adds me to the humans.txt

## What is the current behavior?

Tobi isn't in the list.

## What is the new behavior?

Tobi is in the list.

## Additional context

<img width="4608" height="3456" alt="IMG_20210220_105358_Bokeh"
src="https://github.com/user-attachments/assets/989aadfd-e56b-4227-9adb-ae88b22af866"
/>


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Documentation**
  * Added Tobias Pfeiffer to the remote team member list.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.

YES

## What kind of change does this PR introduce?

Bug fix

## What is the current behavior?

Fixes #48672.

The SQL Editor results grid calculates each column's initial width from
cell values only. When a long final column contains a short value such
as `NULL`, scrolling to the end of a wide result set reveals a truncated
header even though the full column name is needed to identify the
result.

### Before

<img width="760" height="370" alt="Before: final SQL result column
header is truncated"
src="https://github.com/user-attachments/assets/f73b7540-fc45-4ddf-91b6-996afe41807e"
/>

## What is the new behavior?

The initial width now accounts for both the column name and its cell
values while preserving the existing minimum and maximum width
constraints.

### After

<img width="760" height="370" alt="After: full SQL result column header
is visible"
src="https://github.com/user-attachments/assets/b289ab86-4277-46fc-ae9a-35c3eac5442f"
/>

## Additional context

The width calculation was extracted into a utility and covered for:

- short headers and values
- headers longer than their values
- values longer than their headers
- empty result sets
- maximum-width capping

Verification:

- `pnpm --filter studio exec vitest --run
components/interfaces/SQLEditor/UtilityPanel/Results.utils.test.ts
tests/components/SQLEditor/Results.test.tsx`
- `pnpm --filter studio run typecheck`
- `pnpm --filter studio run lint:ratchet`
- `pnpm run test:prettier`
- `SKIP_ASSET_UPLOAD=1 pnpm run build:studio`


<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **Improvements**
- SQL query results now automatically size columns based on their
headers and content.
- Column widths remain within practical minimum and maximum limits for
improved readability and usability.

- **Tests**
- Added coverage for minimum and maximum widths, content-based sizing,
and empty result sets.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

A table RLS policy created via SQL without a `USING`/`WITH CHECK` clause
stores `null` for that field, and the policy editor's payload diff
skipped `null` fields entirely — so adding an expression later through
the dashboard closed the panel as if saved but persisted nothing. This
fixes the diff so those policies are editable, and cleans up adjacent
issues in the same code path.

**Changed:**
- Extracted the update-payload diff from `PolicyEditorPanel`'s submit
handler into a pure `generateUpdatePolicyPayload()` in
`PolicyEditorPanel.utils.ts`. A stored `null` definition/check now
counts as empty, so typing an expression into a previously empty editor
produces a payload field. The diff is branched by command so INSERT
policies only ever emit `WITH CHECK`, never an invalid `USING` clause.
- The required-expression validation ("Please provide a SQL
expression…") now applies only when creating a policy. When updating, a
`null` clause is valid, so rename-only and role-only saves on such
policies work; the update path instead rejects attempts to clear an
existing `USING`/`WITH CHECK` expression with an inline error (`ALTER
POLICY` can only replace an expression, not remove it).
- Saving with no changes now closes the panel without a round trip —
previously a null-vs-undefined comparison injected a
present-but-`undefined` payload key, which sent a literal `BEGIN;
COMMIT;` to the user's database.
- Fixed the unsaved-changes check comparing the form's lowercase command
against `'INSERT'` (never matched), which made closing an untouched
INSERT policy editor prompt about unsaved changes. It now compares
`selectedPolicy.command`.

**Added:**
- `PolicyEditorPanel.utils.test.ts` — 11 unit tests covering null→value
transitions for definition and check, INSERT command mapping,
value→value updates, no-op saves, and empty-value handling.

## To test

- Run in the SQL editor: `create policy "p1" on <table> for delete to
authenticated;` (no `USING` clause), then edit `p1` in Database →
Policies, add a `USING` expression, and save. Confirm via `select
pg_get_expr(polqual, polrelid) from pg_policy where polname = 'p1'` that
the expression persisted.
- Same for INSERT: `create policy "p2" on <table> for insert to
authenticated;`, then add a `WITH CHECK` expression via the editor and
confirm `polwithcheck` is set (and `polqual` stays null).
- On `p1` (still without a `USING` expression? recreate it if you added
one), rename the policy without touching the expression editors — the
rename should save successfully.
- Edit a policy that already has a `USING` expression, change it, and
confirm the new expression persists (regression).
- Open a policy and save without changing anything — the panel should
close with no `policy-update` network request.
- On a policy with an existing `USING` (or `WITH CHECK`) expression,
clear that editor and save — an inline error should appear and no
request should fire.
- Open an INSERT policy that has a `WITH CHECK` expression, change
nothing, and close the panel — it should close without an "Unsaved
changes" prompt.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->

## Summary by CodeRabbit

* **Bug Fixes**
  * Policy updates now submit only changed fields.
* Improved handling of policy expressions, including INSERT-specific
mappings.
* Prevented removal of existing `USING` or `WITH CHECK` expressions
where unsupported.
  * Empty expressions are omitted from update requests.
  * Updates are canceled when no changes are detected.

* **Tests**
* Added coverage for unchanged policies, expression updates, name and
role changes, and INSERT policy behavior.

<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>

…gnostic (#48664)

## Problem

After merging [#48456](#48456)
(shared components) and
[#48459](#48459) (per-page
content fixes), a follow-up diagnostic pass found 22 remaining
heading-order violations, logged as Pass 2 in the [triage
report](https://app.notion.com/p/supabase/Playwright-E2E-Triage-Reports-3ab5004b775f81e3bc60d058fa5a02c1).
None of them were caught by the earlier fixes because they came from
places that scan didn't check: shared partials, raw HTML heading tags
written directly in MDX, and a couple of shared/interactive components
rendering hardcoded heading levels.

## Solution

- `_partials/social_provider_setup.mdx`: `#### Local development` →
`###`, matching the `##` that always precedes it on all 14 social-login
pages.
- `guides/database/functions.mdx` and
`guides/integrations/vercel-marketplace.mdx`: replaced raw `<h4>`/`<h5>`
tags with correctly-nested real headings (`### Planets`/`### People`;
`#### Deploy a Next.js app...`) — no styling workarounds needed since
they nest naturally one level below their parent section.
- `auth/quickstarts/{nextjs,react-native,react,astrojs}.mdx`: these 4
pages had no heading at all before the embedded
`_partials/api_settings.mdx` partial's own `### Get API details`
heading, so added a `## Quickstart` heading above the walkthrough to
give it a valid parent.
- `packages/ui`'s `Accordion` component: Radix's
`AccordionPrimitive.Header` renders as an unconditional `<h3>`
regardless of where the accordion is used. That's shared across Studio,
www, and design-system, not just docs, and surfaced on docs'
vendor-agnostic telemetry page. Now rendered via `asChild` onto a plain
`div` instead, since a generic accordion has no way to know what heading
level (if any) is valid in a given page.
- SQL-to-REST translator tool (`/docs/guides/api/sql-to-rest`): its
`Assumptions`/`FAQs` section labels were hardcoded `<h3>` with no `h2`
anywhere on the page. Converted to styled spans rather than promoting to
a real `<h2>`, because real h1/h2/h3 tags in this codebase force a prose
font-size that utility classes can't override — promoting the tag would
have visibly changed its size.
- `RealtimeLimitsEstimator` (embedded on both `postgres-changes` and
`benchmarks`): its 3 section headings were hardcoded `<h4>`, but the two
embedding pages need different levels (h3 vs h4) for that spot to be
valid — no single correct heading level. Converted to styled spans, same
pattern used throughout this project for components embedded at varying
heading depths.

## Manual testing

1. Check out this branch and run `pnpm dev:docs`.
2. Visit `/docs/guides/auth/social-login/auth-github` (or any other
provider page) and confirm the "Local development" callout under "Find
your callback URL" still looks and reads the same.
3. Visit `/docs/guides/database/functions` → "Returning data sets" tab
and confirm the "Planets" / "People" table captions still look the same.
4. Visit `/docs/guides/integrations/vercel-marketplace` → "Quickstart" →
"Via template" and confirm the CTA card title still looks the same.
5. Visit `/docs/guides/auth/quickstarts/nextjs` (or
react-native/react/astrojs) and confirm a "Quickstart" heading now
appears above the walkthrough, and "Get API details" still renders
correctly further down.
6. Run `pnpm dev:design-system` and open
`/design-system/docs/components/accordion` — expand/collapse an item and
confirm it still animates and looks identical; inspect the DOM and
confirm the trigger's wrapper is a `div`, not an `h3`.
7. Visit `/docs/guides/api/sql-to-rest`, translate any query, and
confirm the "Assumptions"/"FAQs" section labels still look the same.
8. Visit `/docs/guides/realtime/postgres-changes` and
`/docs/guides/realtime/benchmarks`, scroll to the connection-limits
calculator, and confirm its section labels still look the same on both
pages.
9. (Optional, for a full re-check) Run `pnpm e2e:docs:a11y --all`
against a deployed preview of this branch — only `/docs/guides/cli`
(pre-existing 404, unrelated to headings) should fail; every other page
should pass.

Verified with a full Playwright run against a real preview deployment:
**756 passed, 1 failed** (`/docs/guides/cli`, the pre-existing unrelated
404). Zero heading-order violations remain.

<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit

- **Documentation**
- Added clearly labeled Quickstart sections to Astro, Next.js, React
Native, and React authentication guides.
- Improved heading hierarchy and formatting across social provider
setup, database functions, and deployment documentation.
- Updated estimator and SQL-to-REST section presentation for more
consistent content structure.

- **Bug Fixes**
- Improved accordion trigger layout while preserving existing behavior,
styling, accessibility, and icon display.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

---------

Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>